1. Technical Field
The invention relates to push technology as used in connection with computer networks. More particularly, the invention relates to the interpretation and handling of multiple push protocols as used with a computer network and efficient distribution of the resulting information to a client.
2. Description of the Prior Art
Push technology distributes information that constantly or periodically changes, such as stock market quotes, to clients via computer networks. Referring to FIG. 1, push technology first generation products require the clients 101, 102, 103, and 104 to poll the server 105 constantly with requests for any information changes 106. Unfortunately, the constant polling floods the servers.
With respect to FIG. 2, true push technology occurs when the server 201, rather than the clients 203, 204, 205, and 206, initiates the event. The server 201 pushes out a message 202 to all of the clients 203, 204, 205, and 206 which tells them that this is the new content. This approach is much more efficient than the previous method because there is only traffic across the network when something has actually changed, i.e. when an update is required.
Many different protocols are used in the push arena. Thus, there is a need to subscribe to multiple protocols because of the lack of a standardized protocol. This presents a problem because it is unknown which of the protocols are the proper protocols to choose. Vendors must protect themselves against selecting the wrong protocols and also against the need to replicate the interpretation software every time a protocol is added or deleted. Most vendors simply select one protocol because they do not have a solution to this problem.
One multi-protocol approach specifies the Universal Resource Locators (URL) of items that make up a pushed channel and can be extended to include URLs of items that are delivered via push. However, this approach is only useful for pushed channels and it is not applicable to other types of pushed content, such as notification (also referred to as instant messaging). Additionally, this approach defines a URL for each item pushed, therefore it is not possible to have a pushed channel with a dynamic structure. Rather every item must be previously planned for and identified in a definition file. Finally, this approach defines pushed content with the same namespace (URLS) as pulled content, which is a poor design. A URL is not meant to refer to a stream of content, it properly refers to one item.
It would be advantageous to provide a unifying push framework system that handles and interprets multiple push protocols and distributes information to clients. It would further be advantageous to provide a unifying push framework system that is easily configured and adapted to protocol changes and additions/deletions.